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VIRTUAL SOLDER 


Dr. Thomas Scherer 


Even experienced electronics engineers occasionally tind 
themselves confronted by the need to swap soldering iron for 
keyboard: not all projects can be realised purely in hardware. 
LabVIEVV makes an excellent choice of programming 


language for engineers! 


When a PC forms an integral part of a technical solution 
and no suitable software is available off the shelf, some 
programming is required. There are various solutions to 
this problem: suitable modern programming languages 
include C in its various forms such as C++ or C#, Visual 
Basic from Microsoft, Delphi from Borland or even Lab- 
VIEW from National Instruments (NI). 

Visual Basic is designed rather for smaller applications, 
whereas C has for a long time been a universal tool. Del- 
phi is an alternative for those who are not comfortable 
with C’s idiosyncrasies and prefer the structured style of 
Pascal. The majority of all large applications and all 
modern PC operating systems are written in C: and with 
good reason. This gives rise to the generally-held opinion 
that ‘real programming’ should be done in C, since C, of 
all the third-generation languages, produces the most ele- 
gant and fastest solutions. So what about LabVIEW? 


Fourth-generation language 

First, all the arguments that persuaded Microsoft, Apple, 
Linus Torvalds and many other professional programmers 
to use C as the basis for various operating systems are 
quite beside the point for the casual programmer. What 
counts is only how much effort it takes to write a good 
program. And by ‘good program’ we mean one that 
does not just function correctly in principle, but one that is 
above all else reliable and easy to use. 

When you consider that, when you buy a PC today, 
you have to download some 100 MB of patches and 
extensions from the Internet in order to bring Windows 
XP up-to-date, perhaps you might think twice before using 
C. Every month Microsoft issues updates to fix bugs and 
close security holes. And this is not just to question the 
abilities of the Microsoft software engineers: the situation 
is no different for OS X or Linux. The complexity of the 
software is not solely to blame for the problem. Also at 
fault is the programming language. C does not make it 
easy to find errors, and nor does it help to avoid them in 
the first place. C is just text, and typing errors can easily 
creep into text files. Modern software consists of incredi- 


ble amounts of text (Windows, for example, is millions of 
lines of code). Even understanding it in outline is a sci- 
ence in itself. A casual programmer has neither the know- 
how nor the organisational means to get a complex 
piece of software into a usable state in a reasonable 
amount of time. 

Of course this problem did not just arise yesterday, and 
there have been solutions available for some time: fourth- 
generation programming languages. Essentially these are 
program generators that, usually with the help of a 
graphical user interface, create the actual code accord- 
ing to the abstract arrangement of functional blocks and 
control units. This high level of abstraction makes devel- 
opment much faster, since there is no need constantly to 
reinvent the wheel. 

This is akin to developments in electronics where inte- 
grated circuits are now used instead of discrete compo- 
nents. It is clear that integrated circuits, which offer 
ready-made professionally-optimised subsystems, allow 
an individual to solve more complex problems than 
before, and with a drastically reduced likelihood of mak- 
ing a mistake. In software this in analogous fo a program 
generator that produces code which has been optimised 
and thoroughly tested by professionals. 

Of course there are also disadvantages. The conse- 
quence of a higher level of abstraction is an inevitable 
loss of flexibility. Solutions can no longer be tailored so 
precisely to particular problems. The programs do not 
run as quickly as those written in C, and the files gener- 
ated are considerably larger, in the same way as the 
number of transistors in an integrated circuit has grown 
explosively. However, in view of the sizes of hard disks 
and memory available today, the large files do not 
present a problem. The difference in speed is relatively 
small these days (and an assembler program is gener- 
ally faster than one written in C). The limited flexibility, 
however, definitely makes a difference: program gener- 
ators are not equally good in all applications. They are 
more or less specialised to certain application areas 
such as databases, data capture, or measurement, con- 
trol and regulation. 
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Unfortunately our analogy now breaks 


LabView: programming 
for electronics engineers 
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down: ICs from different manufactur- 
ers are generally compatible with one 
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another: this is not the case with pro- 
gram generators. A piece of code 
from one manufacturer cannot be com- 
bined with one from another (as if one 
had to buy a complete set of ICs from 
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a single manufacturer). This also goes Numeric Input 
for LabVIEW. a 
Besides factors such as the compre- 3 2,90 


hensiveness and the range of functions 
provided, an important selection crite- 
rion is the level of maturity of the 
included modules. Another factor that 








should not be underestimated is the 

size of the user community for support. 
It is also important to consider the field 
in which the programming language is 
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to be used. Ultimately one is going to 
sell a product, and if the prospective 
customer's technical department turns 
up its nose (justifiably or not), then you 
have a small problem. 

In this regard LabVIEW presents no 
great difficulties. In the car industry 
the use of LabVIEW for measurement 
and testing is standard from Alfa 
Romeo to Volvo. LabVIEW can be 
found somewhere in practically every 
field of scientific endeavour. And, as 
product cycles get shorter, the sheer 
flexibility of LabVIEW is becoming 
more and more highly valued in the 
production environment. 

Overall, then, LabVIEW offers the most mature fourth-gen- 
eration language code base and the largest developer 
community in the fields of measurement, test and control. 
However, LabVIEW is no software jack-of-all-trades: you 
could not, for example, write an office suite using it, 
although it is perfect for instrumentation data processing. 
The most important limitation is that LabVIEW may not, 
according to the manufacturer, be used in safety-critical 
applications. NI is covering itself here from a legal 
point of view: it is hard to find any practical reasons 
not to use it. 


What is LabVIEW? 

The first version of LabVIEW (1.0) appeared in 1986, ini- 
tially only for the Apple Macintosh computer. At that 
point the Mac itself was already two years old and repre- 
sented a revolution in user-friendliness in the history of 
personal computing. Text-based entry was replaced by 
graphical metaphors, including a desktop with windows, 
waste basket and mouse. High-resolution bitmapped dis- 
plays replaced the chunky graphics we were accustomed 
to from DOS and its cousins. NI translated this metaphor 
into the field of measurement and test. 
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At that time various computer-controlled instruments had 
already been available for some time, although they 
were very expensive. They were based on the GPIB (gen- 
eral purpose interface bus). The essence of NI’s idea was 
to create a graphical programming interface where these 
instruments were represented by icons. In addition, math- 
ematical functions, input units (such as switches) and out 
put units (such as LEDs or oscilloscope displays) were 
also represented using graphical symbols. The icons 
were linked not by a couple of lines of code, but by a 
kind of ‘wire’. Following the metaphor, the corresponding 
tool is represented in the user interface by a wiring pen, 
as frequently used in prototyping. 

Figure 1 shows the appearance of a very simple 
arrangement of data source, data processing and data 
display units, forming a ‘wired circuit’. The program does 
simply this: the input value entered on the control panel 
(2.5) is multiplied by a factor (2), and the result (5) is dis- 
played on the scale of a simulated analogue meter. The 
function is displayed in the diagram using an amplifier 
symbol with the factor 2 shown. Wires run from the 
numeric input unit and the constant to the two inputs of a 
multiplier unit, and from the output of the multiplier to the 
input of the output unit. 

Data and numeric values, rather than currents, flow 


Figure 1: Front 
panel for the 


example program 


and (below) its 
‘code’. 
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Figure 2: A selection 
of the LabVIEW tool 
palettes gives only 
an approximate 
impression of the 
enormous range of 
functions available. 
Most of the icons are 
in other palettes, 
with hundreds of VIs 
in total. 


through these virtual wires, in this example from left to 
right. A module or icon executes its function when data 
are present at all its inputs. The sequence of processing 
operations is therefore not like that in normal program- 
ming languages where the flow of the text is followed 
from top to bottom (except where jumps occur), but 
depends instead on the flow of data. This is called a data 
flow driven architecture and gives great flexibility. NI 
generally refers to the individual modules as Virtual Instru- 
ments (VIs). An important further consequence of the 
architecture is that a number of independent (that is, not 
interconnected) Vis can be placed in a diagram and they 
will be processed in parallel: multitasking is thus a built-in 
feature of LabVIEW. 

Further, it is possible to select either a part or the whole 
of such a module, along with its wiring, and with the 
click of the mouse bring it into a new module which can 
have its own icon. In this way code can be written once 
and then easily reused. This process is analogous to the 
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organisation of code in normal programming languages 
into functions and procedures. In LabVIEW, by compari- 
son, things are much more transparent. 

From our example we can clearly see that programming 
in this style is the most natural process imaginable. It is 
very similar to drawing a circuit diagram, where the indi- 
vidual VIs represent electronic components. It is an easy 
intuitive step to go from constructing electronic circuits to 
programming in LabVIEW. For classically-trained pro- 
grammers and computer scientists, on the other hand, 
accustomed to the traditional methods of writing soft- 
ware, this technology takes some getting used to. A com- 
pletely new way of thinking is required. Perhaps they 
would find it worth changing? 


What can LabVIEW do? 


LabVIEW has practically everything one would expect 
from a normal programming language: all the usual vari- 
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able types from bits through double-precision floating- 
point to arrays and compound types. Even complex num- 
bers are available. It can in some cases calculate directly 
with physical units. The usual constants from e to the gas 
constant R are available to high accuracy. Of course, alll 
the usual control structures can be implemented using 
various types of loops and other commands: it is not com- 
pulsory simply to execute everything in parallel. 
Debugging is possible using single-stepping and semi- 
automatically. Values of selected variables can be dis- 
played at any time using so-called ‘probes’ (analogous to 
test points in electronics). Memory allocation can also be 
controlled. 

The most outstanding feature of LabVIEW, however, is the 
incredible number of ready-made Vis for practically any 
application. There is the full range of usual mathematical 
operations including trigonometric and logarithmic func- 
tions, as well as an arsenal of VIs for string and array 
processing, and for file I/O. Of particular interest to elec- 
tronics engineers will be the wealth of filtering functions 
offering all the usual filter characteristics with adjustable 
parameters. There are also VIs for spectrum analysis 
(FFTs) and complex waveform-related functions such as 
peak detection. Results can be displayed using two- 
dimensional display units (analogous to an oscilloscope) 
or in three dimensions. Simple database and statistical 
functions are also available. 

The importance of integrated support for communications 
protocols and various types of bus should not be underes- 
timated. Not only are GPIB, CAN and serial ports sup- 
ported, but there is also a complete set of Internet proto- 
cols. It is therefore straightforward to implement remote 
measurement and control applications, without having to 
learn a great deal about network technologies. 

Last but not least we should mention the large number of 
data acquisition cards available with PCI or PXI inter- 
faces. There is no major vendor of such cards that does 
not offer a driver for LabVIEW, allowing one to configure 
and use a card in a hardware-independent fashion using 
abstract Vls. Figure 2 shows some of the typical Lab- 
VIEW tool palettes with their corresponding VIs. 

If the functions built in to LabVIEW are not sufficient, 
there are many software companies that offer optimised 
‘tool sets’ for specific areas, such as the chemical indus- 
try, electronics for the construction industry, quality con- 
trol, automotive technology, vibration analysis, image 
processing, video monitoring etc. It is possible to write 
your own low-level Vis in C and integrate them: examples 
and support are available. 

On the subject of support: early versions of LabVIEW 
came with about half a metre of manuals, but today all 


the documentation is provided on CD or in the form of 
context-sensitive help, so that with a little experience you 
will practically never need to look anything up. 


What else can LabVIEW do? 


Any program created using LabVIEW can be stored as a 
collection of VIs in an individual file which can then be 
run (within the development environment) with a double- 
click. There is also a compiler which can generate EXE or 
DLL files, protecting your ideas from being copied. 
For those hardy souls who want to integrate fragments of 
LabVIEW code in their projects written in C there is a 
special version of LabVIEW available in the form of a C 
code library. A further version is available to run code 
generated by LabVIEW on dedicated single-board 19- 
inch rack computers, making it possible to build real-time 
instrumentation systems. 
There is little else to note: LabVIEW is available for all the 
main operating systems (Windows, Mac OS 9, OS X, 
Linux, Solaris and HP/UX) and changing between plat- 
forms is straightforward. LabVIEW is also available for 
PDAs and FPGAs and in foreign languages. However 
LabVIEW is not cheap: a standard licence costs in the 
region of seven hundred pounds, and the complete pack- 
age including compiler and other functions costs around 
three thousand pounds. In view of the range of functions 
provided and the possible time savings, this seems rea- 
sonable. Research suggests that a threefold increase in 
productivity can be obtained, which the author can con- 
firm from his own experience. 
A significantly cheaper version, LabVIEW Express 7, is 
available to school pupils and students. It costs around 
twenty pounds and offers full functionality, but of course 
may not be used for commercial purposes. 
Special prices are also available to universities buying a 
number of licences. 
If you wish to try out LabVIEW, a free demonstration ver- 
sion, offering full functionality but time-limited to thirty 
days, is available from NI. 

(040237-1) 


Web pointers 


http://encyclopedia.thefreedictionary.com/ 
Ath%20Generation%20Language 


http://www.ni.com/labview 
http://www-w2k.gsi.de/labview/document.htm 
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